This section (and much of this manual) assumes that you are administering your list by mail, which is the "traditional" method of LISTSERV list administration. LISTSERV also includes a web-based administration interface for lists (described in Section 11
Using the Web Administration Interface). Lists that are coded "
Validate= Yes,Confirm,NoPW" or "
Validate= All,Confirm,NoPW" must be managed by mail, since the Web Administration Interface is secured by passwords and these settings reject password validation, instead requiring validation by the "OK" confirmation method. If you use the web-based tools to manage your list, you should still skim this section and refer to it for more advanced list management information.
Before you start your list, it pays to do a careful search in several places to find out if you are duplicating an already-existing list, or if the name you are considering is already in use for a list on a differing subject. The first place to check is the "CataList" service maintained by LISTSERV itself. This service lists all public lists running on LISTSERV servers worldwide. Point your Web browser of choice at the URL
http://www.lsoft.com/CataList.html to access CataList. If you don't have a web browser, you can alternately send the command
LISTS GLOBAL search_string in the body of mail to LISTSERV@LISTSERV.NET (or to LISTSERV at any host site). You will receive a mail message in return containing a list of all lists known to LISTSERV where either the name of the list or the short list description contains your search string. For instance, LISTS GLOBAL IBM would result in the following being returned to you:
You might want to make your search more specific, as this particular search locates every list that has IBM somewhere in its title. For instance, if you wanted to start a list on some aspect of the IBM 370, you might do better to search for IBM 370.
You should already be familiar with your mailing system and text editor. Otherwise, there are no special skills required. It is the goal of this manual to give you what you need to know about LISTSERV user commands, privileged LISTSERV owner commands, and how to read and interpret Internet-style mail headers
2. LISTSERV itself is designed to operate in an identical manner no matter which operating system it is running under. Thus the fact that LISTSERV is running under VM, VMS, some flavor of Unix, or Windows NT should not be a concern to the list owner, who may not even know which version of LISTSERV his lists are running on.
Additionally, we have made an attempt to give you a basic "list owner's course" in anticipation of some of the issues you may encounter in the course of moderating a list.
Note: Many sites (predominantly, but not necessarily limited to, those in .EDU domains) will not host commercial or potentially-controversial lists because of internal policies regarding appropriate use of their computing facilities. In such a case, your only option may be to seek a commercial LISTSERV site.
Physically creating the list is the task of the LISTSERV maintainer (sometimes referred to as the "LISTSERV postmaster") at a given LISTSERV host site
3. Specific procedures for requesting a list startup vary from institution to institution. It is usually best to contact the computing center at the site for more information.
Because most list owners do not have the appropriate permissions to create lists, instructions on how to physically create lists are not included in this manual. If you are a LISTSERV maintainer, you can find these instructions in the Installation Guide that came with the software, or in the Site Manager’s Operations Manual for LISTSERV.
The "-L" convention isn't required, but it can help people to realize that the mail is coming from a mailing list rather than from a real person. The people we are referring to here are people who run Internet mail systems, who may see a great deal of mail coming from a single host and begin to wonder why. If it comes from a userid that ends in a "-L", they will be more likely to recognize it as list mail.
owner-*
*-request
*-search-request
*-server
*-signoff-request
*-subscribe-request
*-unsubscribe-request
For instance, lists cannot be made with names like "owner-loyalty", "linux-server", and "donation-request". While it is physically possible to create a list with a name that matches one of the above wildcards, attempts to send mail to the list (for example, a list called "linux-server") will result in an error, logged as follows in the LISTSERV log:
These "pseudo-mailboxes" have a special meaning to LISTSERV, which has internal rules that govern how mail sent to these addresses is handled. See the
Site Manager’s Operations Manual for LISTSERV for more information on what happens to mail sent to these special addresses.
It is best if you avoid the use of special characters altogether and stick exclusively to the letters A-Z, numbers 0-9, and the underscore and hyphen characters when naming lists. Note that the "_" (underscore) character may cause problems with some non-compliant receiving systems. Also note that the space character (ASCII 0x20) is illegal in a list name, and L-Soft recommends that, although apostrophes (aka "single-quotes", ASCII 0x27) are valid in an RFC822 username, they should not be used in list names since some mail programs may not accept them.
Note: L-Soft recommends using names of 32 characters or less whenever possible as they provide for correct alignment of the results returned by certain commands. Very long (for example, program-generated) list names are likely to conflict with mail system limits and L-Soft recommends other solutions to the problem of dynamically generated lists. As a rule, list names in excess of 70 characters are likely to result in mail delivery problems.
No doubt you could name a list MY-LIST-FOR-MATH-STUDIES, but who wants to type that? Conversely, MLFMS-L wouldn't mean much to Joe Random User. Somewhere in the middle is a reasonable compromise, for example, MATH-STUDIES (or even just MATH-S).
How a LISTSERV mailing list performs its tasks is defined by its header keywords. There are several different categories of keywords, each of which is discussed below in general terms. We will discuss these keywords in detail in subsequent sections, and a complete alphabetical listing of list header keywords, including default settings and all options available, is provided in the
List Keyword Reference document.
•
Access Control Keywords – These keywords designate the level of "openness" for a list. They determine who can post to the list, who can review the list of subscribers, and whether or not the list is open to general subscription.
•
Distribution Keywords – This group has to do with how LISTSERV distributes postings to subscribers, including whether or not acknowledgments are sent back to posters, how many postings may go through the list daily, whether or not the list is available in digest form and whether it is available to USENET through a gateway. These keywords also determine whether or not list topics are enabled, and how LISTSERV will configure outgoing postings for replies.
•
Error Handling Keywords – Included under this group are the keywords controlling automatic deletion, loop-checking, and to whom error messages are sent for disposition when received by LISTSERV.
•
List Maintenance and Moderation Keywords – A fairly large group of keywords having to do with how the list is operated, including definitions for the list owner, list editor, and the list archive notebook; whether or not (and who) to notify when users subscribe and sign off; how often subscriptions must be renewed, and so forth. These are perhaps the most basic keywords that can be set for a given list, and one of them ("Owner=") must be set for a list to operate.
•
Security Keywords – These keywords control who can "see" the list (that is, whether or not the list appears in the List of Lists for a given user, based on the user's host site), whether or not the list is protected by a password, and the level of security necessary for changes to the list itself. The "Exit=" keyword is also contained in this group.
•
Subscription Keywords – These control whether or not the list is open to general subscriptions, whether or not a mailing path confirmation is required, and what user options are set by default upon subscription.
•
Other Keywords – These control other aspects of list management that are not generally changed from their defaults, and which do not fit readily into the categories listed above.
In the following sections, you will see numerous references to "sending commands to LISTSERV". All LISTSERV commands are sent to the server either by email or via the web administration interface described in
Section 11
Using the Web Administration Interface. For mailed commands, this means that you must create a new mail message using whatever command this requires for your mail client (click on "New message" or its equivalent for most mail clients) addressed to the LISTSERV address. Let’s say for the sake of argument that the list you want to subscribe to (or are currently subscribed to) is running on a server called
LISTSERV.MYCORP.COM. In order to send a command to that server, you would create a new message and address it to
LISTSERV@LISTSERV.MYCORP.COM, and place the command(s) in the body (not the subject) of the message.
The passwords recognized by LISTSERV for various operations (assuming that the NOPW parameter is not used with the "
Validate=" keyword) are of two distinct types:
•
Personal Passwords – LISTSERV can store a personal password in its signup files corresponding to your userid. This password not only can be used for list maintenance operations, but also protects your FUI (file update information) and AFD (automatic file distribution) subscriptions (if available on your server) and must be used to store your archive files, if any, on the server.
•
List Passwords – List passwords are obsolete except in only one special case (peered lists). We mention them here only because users upgrading from earlier versions will be aware of their existence. You should define and use a personal password for all protected operations.
If you do not include the old password in the command (e.g., you’ve forgotten it), LISTSERV will request an "OK" confirmation. Otherwise, it will act on the command without need for further confirmation (unless, of course, the oldpassword provided is incorrect).
Warning: Never attempt to hand-edit a production list file in place and restart the server. The GET and PUT operations are the only supported methods. Particularly under unix and Windows, LISTSERV will not always accept the hand-edited list file because some editors will insert control characters or CR-LF combinations that LISTSERV cannot parse. Under VM or VMS, it is always possible that hand-editing the list will introduce some sequence that will cause an operational error. L-Soft suggests that this method be used sparingly, if at all, and does not support it.
In general, any email address specified explicitly as a list owner (in the Owner= list keyword setting) may retrieve, edit, and store the list configuration (also known as the "list header").
If the list header keyword Configuration-Owner= is set, then only those list owners specified in both Owner= and Configuration-Owner= may retrieve, edit, and store the list configuration. All other owners (that is, those not specified in Configuration-Owner=) may perform other list maintenance duties, such as adding/deleting subscribers or modifying their subscription options. The Configuration-Owner= keyword is "protected" and can be changed only by someone with LISTSERV site maintainer privileges.
The LISTSERV site maintainer has "super-owner" privileges and may edit all list configurations on the server regardless of the setting of Owner= or Configuration-Owner=.
Note: You can retrieve the entire list, subscribers and all, by omitting the
(HEADER switch. However, L-Soft strongly discourages getting the entire list at any time. This is because you do not need the entire list file if all you want to do is to change list header keyword settings. Also, since LISTSERV has well-documented commands available to manage user subscriptions, you should never attempt to hand-edit a list file in order to add or delete subscribers. Therefore there should normally be no reason to issue the
GET listname command without the
(HEADER switch.
The GET command automatically locks the list so that no changes can be made to the operating copy on the server until you do one of two things:
•
Issue the UNLOCK listname command (if you decide no changes are needed).
Leaving the list locked also prevents new subscribers from signing up. It is therefore not advisable to leave the list locked for long periods of time. This necessitates remembering to issue the
UNLOCK command if you decide not to make any changes.
It is possible to request that LISTSERV not lock the list when it is sent to you. This is accomplished by adding the
(NOLOCK switch to the
GET command. You can use
(NOLOCK and
(HEADER together as in the following example:
Note: The "
(" switch character is used only once.
Caution: It is not advisable to use the
(NOLOCK switch in at least two cases:
Don't use the
(NOLOCK switch if you are not the sole owner of the list. This prevents conflicting GETs and PUTs by different list owners. For instance, Owner(A) GETs the list without locking it. Owner(B) then also GETs the list. The owners make differing changes to the list header. Owner(B) PUTs his changes back first. Owner(A) then PUTs his changes back, erasing every change Owner(B) made. If Owner(A) had not used the
(NOLOCK switch, Owner(B) would not have been able to GET a copy of the list until Owner(A) either unlocked the list or PUT his copy back. (Owner(B) could also unlock the list himself, but it would be advisable to ask Owner(A) if he was finished editing the list header before doing so.)
Don't use the
(NOLOCK switch if you get the entire list rather than just the header. You will erase all subscriptions for users who subscribed between the time you GET the list and PUT the list back. It is easier to deal with questions as to why they got the "listname has been locked since time by list-owner" message than to explain why they got a subscription confirmation and now aren't getting list mail.
Note: A PUT command containing new subscribers added "on the fly" will result in only the header of the list being updated and a warning being generated that says if you really wanted to PUT the entire list, subscribers and all, that you should use the PUTALL command.
LISTSERV maintainers should note one further caution: It is considered extremely inadvisable to "hand-edit" subscriber lists, as columns at the far right of each subscriber's entry contain list control codes corresponding to the subscriber's personal option settings. The only case in which it might be appropriate to "hand-edit" would be to delete a user entirely, and then only if all attempts to delete the user via the DELETE command fail. For instance, X.400 or X.500 addresses can cause DELETE to fail because of their use of the "/" character. You can use wildcards to delete these subscriptions:
Finally, depending on your list configuration, you may have to use a password or respond to a confirmation request in order to GET your list header. The syntax for using a password with the GET command is
Once the LISTSERV maintainer has notified you that the basic list has been created, you can send a GET command to the server to make any modifications necessary, as explained above. For instance,
In Figure 2-3, we've made some changes to the list header and it is ready to be included in a mail message and sent back to LISTSERV. Note that the PUT command has been modified to include your personal password (see Section 2.6
Defining Personal Passwords for instructions on how to obtain a personal password).
List owners should be persons who will undertake the responsibility of managing the list in all of its aspects. A list owner may be a moderator; a list owner may be called upon to determine why a user can’t unsubscribe from the list, or to handle delivery errors, or to fix other problems that may arise.
The primary list owner (the first owner defined) has special responsibilities as well. This owner is considered the Editor and the primary Moderator for lists that have Send= Editor but do not have Editor= or Moderator= defined. This owner receives all error messages when Errors-To= is set to "Owner". In short, the primary list owner is generally the person who is ultimately responsible for the workings of the list.
Notes: All list owners defined after the
* Owner= Quiet: line will be quiet list owners.
You can define multiple owners on a single line by separating them with a comma. If you put "
Quiet:" on a line with list owner userids, you must place a comma after "
Quiet:", e.g.
* Owner= Quiet:,ncbnet@linus.example.com,cheng@linus.example.com
There must
always be at least one non-quiet list owner. Otherwise LISTSERV sends all error messages and other administrative mail to the LISTSERV maintainer by default.
When you are ready to store your list back on the host, include the list file in a mail message to LISTSERV. Ensure that the PW=XXXXXXXX command is in the first line of the mail body. Change XXXXXXXX to the personal password you have previously defined with the PW ADD command (see Section 2.6
Defining Personal Passwords). Then, send the message.
If LISTSERV has trouble processing the edited list file, it will return a discrepancy report to you with each error noted. If the errors are categorized as "warnings only," LISTSERV will go ahead and store the list. However, if any one error is categorized as a serious error, the list will not be stored and the old version will be retained.
Caution: If you are using a mail client that allows "attachments" to mail, do not "attach" the list file to your mail message. It must be in plain text with the
PUT line at the top. LISTSERV will not translate encoded attachments.
LISTSERV always backs up the current list file before it stores a new copy. Should you discover that you have made a mistake (for instance, you have deleted all users by storing a header and adding users "on the fly"), it is possible to retrieve the previous copy of the list by issuing a
GET listname (OLD command to the host server. You must then add the
PUTALL listname LIST PW=XXXXXXXX command to the top of the file and store it. (
PUTALL is used in this case since you are storing the entire list, not just the list header.)
LISTSERV’s security options are wide ranging, from almost no protection (easiest to administer a list, but also most open to hacker attacks) to total protection requiring validation of each and every command sent to LISTSERV for the list. It is also possible to limit access to various aspects of the list, such as who can subscribe, who can review the list of subscribers, and who can access the list archives. The list can be hidden from the LIST command, either at the global level or from all requests, including those from users on LISTSERV’s local machine, or from a definable range in between.
Note: LISTSERV does not set any file system permissions for any files. LISTSERV's security features are meant to allow and deny access to LISTSERV's various files depending on how various keywords are set, but in order to make your system completely safe, you must ensure that you have also set file and directory permissions appropriately for your operating system. For instance, LISTSERV may deny GET access to certain list archive files to non-subscribers, but if you have not set the appropriate file system permissions at the operating system level, you may have left open a window for someone to reach these files via anonymous ftp.
The VALIDATE= keyword controls the level of command validation desired for the list. The default,
VALIDATE= NO, requires password validation only for storing the list on the server. This is often sufficient for general needs. However, when a list is set this way, LISTSERV only compares the RFC822 "Sender:"/"From:" headers against the Owner= keyword(s) in the list header to determine whether or not the person ostensibly sending the commands has authority to do so. Otherwise at this level LISTSERV does not validate commands it receives for the list, under the assumption that the mail it receives is genuinely coming from a list owner. This level of validation does not protect the list from commands issued by hackers who have forged mail in the name of the list owner. If you run a list on a controversial topic or just don't feel comfortable without at least some security,
VALIDATE= NO is probably not for you.
The next level is VALIDATE= YES. At this level, LISTSERV requires a password for all of its "protected" commands. This password is the sender’s personal LISTSERV password as defined by the
PW ADD command. The commands protected by this level are those that affect subscriptions or the operation of the list, for example,
DELETE or
ADD. Users will also have to validate most commands that affect their subscriptions, but generally can do so using the "OK" mechanism rather than defining a personal password. Note that some user commands will be forwarded to the list owner for validation rather than accepting password validation from the user.
The next level is VALIDATE= YES,CONFIRM. At this level, LISTSERV will require validation with the "OK" mechanism (see below) by default, but will still accept passwords where appropriate. While the less-secure passwords are still accepted, this is considered a good compromise between list security and list owner and user convenience.
The next level is VALIDATE= YES,CONFIRM,NOPW. At this level, LISTSERV will no longer accept passwords as validation for protected commands. The logic is that because of the way the "OK" mechanism is implemented, passwords are not as safe as "magic cookies". This is the recommended setting for lists that must be kept secure.
Two other levels are VALIDATE= ALL,CONFIRM and
VALIDATE= ALL,CONFIRM,NOPW. These levels require "OK" validation for all commands that cause a change in state except for the
PUT command. If
NOPW is not specified, passwords are accepted where appropriate. With these levels, commands that do not cause a change in state (e.g.,
QUERY and other strictly-informational commands) do not require validation.
Note: LISTSERV requests coming from the local system via CP MSG or CP SMSG on VM systems or via LCMD on VMS or Unix systems never require validation, as they cannot be forged.
Lists which are set to either Validate= Yes,Confirm,NoPW or
Validate= All,Confirm,NoPW may not be managed via the web administration interface, which is password-driven.
See the List Keyword Reference document
for complete information on the
VALIDATE= keyword.
Subscription requests are controlled by use of the SUBSCRIPTION= keyword. By default, this keyword is set to
SUBSCRIPTION= BY_OWNER, meaning that all subscription requests will be forwarded to the list owner for disposition. Subscription requests can be refused completely by setting
SUBSCRIPTION= CLOSED.
To code a list for open subscriptions without list owner intervention, set SUBSCRIPTION= OPEN. If it is desired to add protection against forged subscription requests or bad return mailing paths, code
SUBSCRIPTION= OPEN,CONFIRM. The latter will cause a subscription confirmation request to be sent to the prospective subscriber, which he or she must respond to using the "OK" confirmation mechanism.
It may be desirable to restrict access to a list to people in a small area. For instance, you probably would not want a list for students in a class section at a university to be advertised or accessible by people all over the world. However, without setting certain keywords appropriately, such a list will be visible to a
LISTS GLOBAL command.
The local list of (public) lists can be retrieved only by those users who are considered local, per the setting of the server-wide
LOCAL= variable in LISTSERV's site configuration file. All other users will be told that none of the lists on the server are visible via the LISTS command, and will be referred to the use of the
LISTS GLOBAL search-text command or to the CataList. This is regardless of the setting of
Confidential= as outlined below.
To simply hide a list from a LISTS command, but still allow people to subscribe to it if they know it is there, use the keyword
Confidential= YES. Note that users subscribed to the list as well as the list owner(s) will be able to see the list if they issue a
LISTS command. In addition, all other non-subscribers, including users on the local machine, will not be able to determine that the list exists via a
LISTS command.
Service= can also be set to
Service= LOCAL, meaning it will use either LISTSERV’s global definition of which machines are
LOCAL, or the machines defined by the list keyword
Local=. The LISTSERV maintainer should define hosts and nodes that are considered local with the server-wide
LOCAL= variable in the site configuration file. If the global definition is not suitable, it can be overriden by defining the
Local= list header keyword:
If there are many subdomains within your primary domain, it may be preferable to use the wildcard when defining the
LOCAL or
SERVICE list header keywords. For instance:
Note: Defining a service area for a list controls only from which domains subscription requests may be accepted. It does not control who may post to the list. Depending on local circumstances, it may be desirable to set lists with controlled service areas to Confidential= Service.
For whatever reason, it may be desirable to restrict the ability to review the subscriber list either to subscribers or to list owners. This is done by setting the
REVIEW= keyword appropriately.
Reviews can also be restricted to users within the list’s service area by setting REVIEW= SERVICE, and defining the
SERVICE= keyword appropriately (see the preceding section).
Restricting access to the list’s notebook archive files is similar to controlling who may review the list. It is accomplished by setting the fourth parameter of the
NOTEBOOK= keyword to an appropriate value. For instance,
defines a monthly notebook on LISTSERV’s A disk that is accessible by anyone. Change Public to Private if you wish only subscribers to be able to access the notebooks. The same access-levels are available for this keyword as for
REVIEW=. (See the
List Keyword Reference document for a discussion of access-levels.)
It is possible to define "Service=" in terms of IP address blocks in order to limit access to list archive notebooks. See "
Service=" in the
List Keyword Reference document for details.
The Send= list header keyword is the basic control for who may post mail to the list. If the list allows non-subscribers to post, set
Send= Public. (This is the default.)
•
Send= Editor forwards all postings to the list editor (see the
Editor= and
Moderator= keywords). This setting allows the editor to make changes before forwarding the message back to the list. Note that your mail program must be capable of inserting "Resent-" header lines in your forwarded mail—if it is not capable of this, all such posts forwarded to the list will appear to be coming from the editor. Check with your system administrator if you are not sure whether or not your mail program inserts the "Resent-" headers.
•
Send= Editor,Hold forwards a copy of the posting to the editor but differs from
Send= Editor in that LISTSERV holds the posting for a period of time (usually 7 days) until the editor confirms the message with the "OK" mechanism (see below). Unconfirmed messages simply expire and are flushed by LISTSERV, so there is no need to formally disapprove a posting. This method of message confirmation is well-suited to lists where it is not often necessary to modify the text of a posting, and also is an excellent work around if the editor’s mail program does not generate "Resent-" headers in forwarded mail.
•
Send= Editor,Hold,Confirm is identical to
Send= Editor,Hold except that postings coming directly from an editor must be confirmed (with the "OK" mechanism) by the editor who sent the message.
This is the recommended setting for any moderated list or announce-only list as it protects the list from hackers who might try to forge mail from a legitimate editor address.•
A final method (called "self-moderation") exists for lists where subscribers should be allowed to post freely, but non-subscriber posts should always be sent to an editor for approval. To enable self-moderation, set
Send= Editor (or Send= Editor,Hold)
Editor= userid@host,(listname)
Ensure that "listname" is in parenthesis. Note that self-moderation will catch all posts from non-subscribers—including posts from subscribers who are posting from a different address. For instance, if the subscriber originally signed up as joe@foo.com but is posting from joe@unix1.foo.com, LISTSERV will treat his mail as non-subscriber mail. Self-moderation may require some slight changes in individual user subscriptions in order for it to work seamlessly. See also the
Default-Options= list header keyword description.
Depending on the setting of the Validate= list header keyword, certain LISTSERV commands have always required a password for execution. However, with a recognition that mail can be forged ("spoofed") by just about anyone on the Internet today, L-Soft introduced a "magic cookie" method of command validation that is considered much more secure than passwords.
In essence, the "magic cookie" method requires that the sender of the command must confirm his command via a reply containing only the text "OK". (This is actually simplistic; see below.) If mail is spoofed from the list owner’s user id, the command confirmation request will always be sent to the list owner’s user id, thus preventing the spoofer from confirming the command. Moreover, the "cookie" itself (an eight-digit hexidecimal number) is registered to the "From:" user id of the original command. A typical command confirmation request looks like this:
It is also possible to confirm multiple command confirmation requests with a single message (for instance, if you have
Send= Editor,Hold and have a number of requests to be responded to). This eliminates multiple "Message approved" mails from LISTSERV. However, make sure that you send the confirmations in a new mail message rather than replying to one of them. (See the "bracketed OK" syntax mentioned below.)
You can send the "OK" from any address, which helps when the address field of your mail gets changed somewhere along the line. For instance if you are logged into the web administration interface as joe@example.com and issue a command that requires mail confirmation, LISTSERV will send the request to joe@example.com (as expected). If your mail system expands joe@example.com to Joe_Doakes@mail.example.com, the "OK" will still succeed and Joe_Doakes@mail.example.com will get a message that says
> okConfirming:
> QUIET DELETE * jane@example.com
[reply sent to joe@EXAMPLE.COM]
OK BEGIN
command1
command2
...
command3
OK END
Note: In a "bracketed OK" the aggregate length of the data stream (that is, the total number of characters in the command lines falling between OK BEGIN and OK END) MUST be less than 32K characters. In practice you should use bracketed OKs for limited numbers of commands only, say no more than 10-12 at a time. In particular, if you have many ADD or DELETE commands to send, it is far more efficient (and strongly preferred) to use the bulk ADD and bulk DELETE syntaxes described in Section 4.4
Adding Subscribers to Lists in Bulk and Section 4.5
Deleting Subscribers from Lists in Bulk.
(for instance, "OK CANCEL 8F2E8F4B"), and if the cookie is valid, LISTSERV will respond "Confirmation code 8F2E8F4B cancelled." If the cookie is not valid (e.g. has expired, has already been cancelled, or is simply incorrect), LISTSERV will send its standard message telling you in part that "The confirmation code 8F2E8F4B does not correspond to any pending command."
Another security issue involves protecting the list from people who refuse to play by the rules. LISTSERV includes several different levels of privilege restriction for these users; some are available for list owners without the intervention of the LISTSERV maintainer.
1.
The REVIEW personal option setting. By issuing a SET listname REVIEW FOR userid@host command to LISTSERV, you can moderate postings at the individual subscriber level. Postings from subscribers set to REVIEW are passed on to the Editor(s) or Moderator(s) of the list, or, if neither of these keywords are defined for your list, the postings are passed on to the primary list owner. At this point, the person who receives the postings can determine whether or not to approve them. Note that the subscriber always receives notification that his or her posting has been forwarded to a moderator for approval. This is to avoid the impression that the subscriber’s posting has been lost before reaching LISTSERV.
2.
The NOPOST personal option setting. By issuing a SET listname NOPOST FOR userid@host command to LISTSERV, you can prevent a subscriber from posting to the list entirely. LISTSERV will reject postings from these subscribers and will not pass them on to a moderator. As with the REVIEW setting, note that the subscriber always receives notification that his or her posting has been rejected.
3.
The FILTER= list header keyword. You can filter individual users from subscribing and/or posting to your list by adding them to the
Filter= list header keyword. For instance, if you have a list called MACTALK-L and you want to discourage redistribution lists from using the same name as your list, you can add
You can control the maximum number of postings per day per subscriber on a list-by-list basis by setting the optional second parameter of the "Daily-Threshold=" list header keyword. The default is to have no such daily limit per user.
If set, when the per-subscriber threshold is reached, the subscriber is told that his message cannot be processed because he has reached the limit for today, and that he should repost his message at a later time. The counter for this limit resets to zero at midnight for all lists.
If you want to set this limit, note that an overall daily threshold must be set for the list in the first parameter of the keyword. If no "Daily-Threshold=" keyword is already present in your list header, the default is "Daily-Threshold= 50". Thus, to leave the default value in force and to add a daily limit of 5 postings per day per user, you would code:
Public discussion lists have always been the "classic" type of LISTSERV mailing list. Such lists are available to discuss just about everything imaginable. In the last few years it has become desirable to secure mailing lists against random spamming and mail bombing, but no discussion of different types of lists would really be complete without talking about this kind of list.
Typically, a public discussion list is wide-open (although some things, like the ability to review the subscribership, may be restricted). Anyone can subscribe (with a confirmation to verify the mailing path), anyone can post, anyone can read the messages in the archives, and security is set fairly low. Very large lists (hundreds or even thousands of users with hundreds of postings every week) may likely be set up this way as it is a "low-maintenance" way to run a list (and most spams tend to be caught by LISTSERV's anti-spamming filters anyway). For instance, you might have
* My public discussion list (MYLIST-L)
* Subscription= Open,Confirm
* Ack= Yes
* Confidential= No
* Validate= No
* Reply-to= List,Respect
* Review= Owners Send= Public Errors-To= Owner
* Owner= joe@example.com
* Notebook= Yes,E:\LISTS\MYLIST-L,Weekly,Public
to force the default Reply-To: header to point back to the original poster instead of to the list. Note that the ",Respect" option means that if a user sends mail to the list that contains a "Reply-To:" header pointing back to the list (unlikely that this may be), LISTSERV will "respect" that header and use it. If you absolutely do not want this to be possible, you should code the following instead:
Caution: "Reply-To:" are not universally honored!
Note: There is one major caveat with regard to the use of the Reply-To= list header keyword. Setting this parameter guarantees only one thing -- that LISTSERV will generate an appropriate RFC822 Reply-To: header in the mail it distributes to subscribers. THERE IS UNFORTUNATELY NO GUARANTEE THAT THE MAIL TRANSFER AGENT (MTA) OR MAIL CLIENT ON THE RECEIVING END WILL HONOR THE Reply-To: HEADER. This is because some mail clients, out-of-office robots, and Internet MTAs either simply do not recognize the existence of Reply-To: or do not implement it properly. Specifically RFC2076 "Common Internet Message Headers" reports that the use of Reply-To: is "controversial", that is, "The meaning and usage of this header is controversial, meaning that different implementors have chosen to implement the header in different ways. Because of this, such headers should be handled with caution and understanding of the different possible interpretations." (RFC2076, page 4). While L-Soft recognizes that it is sometimes important to provide an explicit Reply-To: header to indicate a response path, L-Soft cannot and will not be held responsible for problems arising from the inability of a remote server to properly process Reply-To: headers.
Private discussion lists are similar to public discussion lists, but with varying restrictions on who may subscribe, who may post and who may view the archives. Such lists are relatively safe from random spamming since typically only a subscriber can post (but note that a spammer spoofing mail from a subscriber's address will probably be successful unless first caught by the anti-spamming filters). For instance:
* My private discussion list (PRIVATE-L)* Subscription= By_Owner
* Ack= Yes
* Confidential= Service
* Validate= No
* Reply-to= List,Respect
* Review= Owners
* Send= Private
* Errors-To= Owner
* Owner= joe@example.com
* Notebook= Yes,E:\LISTS\PRIVATE-L,Weekly,Public
is a low-security private discussion list where subscriptions requests are passed on to the list owner(s) for review, only subscribers may post, and only subscribers may view the list archives. Here again, for more security you might want to set "
Validate= Yes,Confirm", and of course you can have replies go to the original poster rather than to the list with "
Reply-To= Sender,Respect" (with the same caveats as noted in Section 2.13.1
Public Discussion Lists).
An edited list is one that requires a human editor to approve messages sent to the list. Some list software and most USENET newsgroups refer to this as "moderation", but to avoid confusion between two types of moderated LISTSERV lists, the present example will be referred to as an "edited" list.
Examples of edited lists range from refereed electronic journals to lists where the list owner simply wishes to exercise control over which postings are allowed to go to the list.
* Send= Editor
* Editor= someuser@somehost.com
to the basic list header. Note that the primary Editor= specification (that is, the first editor defined by an
Editor= keyword for the list) must be a human person who will be able to act on postings sent to him or her for approval. You may not use an access-level specification (such as "Owner") when defining the primary editor for a list.
Please note that L-Soft recommends setting "Send= Editor,Confirm" so as to add a level of security against malicious users forging mail from an "
Editor=" address to get around your moderation settings, or against badly-configured "vacation" programs that simply reflect the message back to the list in a manner that makes it appear that the mail is coming from the editor’s address. The "Confirm" option causes LISTSERV to request an "OK" confirmation from an editor when it receives mail claiming to be from that editor.
You can define multiple editors, but only the first editor will receive postings for approval. Anyone defined as an editor may post directly to the list without further intervention. Multiple editors can be defined on separate
Editor= lines or can be grouped several on a line, for example,
To approve postings with the above configuration, the editor simply forwards (or "resends", or "bounces"--the terminology is unclear between various mail programs) the posting back to the list address after making any desired changes to the content. This should be done with a mail program that supports "Resent-" fields. if "Resent-" fields are not found by LISTSERV in the headers of the approved posting, then the posting will appear as coming from the editor's address rather than from the original poster. If your mail program does not support "Resent-" fields, you should use the "
Send= Editor,Hold" option and approve messages with the "OK" mechanism described below.
If you do not need to physically edit the content of your users' posts (for instance, to remove anything considered "off-topic" or to remove included mail headers and so forth), you can code
The "Hold" parameter causes LISTSERV to send you a copy of the posting along with a "command confirmation request". To approve the posting, you simply reply to the confirmation request with "ok".
which will cause LISTSERV to request a command confirmation ("ok") from the editor sending the approved posting back to the list. This makes it impossible for an outside user to "spoof" mail from an Editor address.
Finally, please note that the NOPOST subscriber option will take precedence over Editor=, if set for someone defined as an editor. This means that if you have "
Default-Options= NOPOST" for your list and you add an editor as a subscriber, you will have to manually reset the editor to POST (with "
SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor can successfully approve postings but is then told that he or she cannot post to the list.
Note: The
Moderator= keyword is disabled in LISTSERV Lite.
A moderated list is similar to an edited list, but for LISTSERV's purposes it refers to a list that uses the Moderator= list header keyword to "load-share" posting approvals among several editors. It is set up similarly to an edited list, as follows:
* Send= Editor,Confirm* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= yetanotheruser@his.host.com
This list will "load-share" the approval process between the three moderators, who will each receive one-third of the postings for approval. Note that a primary editor should still be defined.
* Send= Editor,Confirm* Editor= someuser@somehost.com
* Moderator= someuser@somehost.com,anotheruser@anotherhost.com
* Moderator= someuser@somehost.com,yetanotheruser@his.host.com
If the parameter "All" is coded at the beginning of the list of moderators, LISTSERV will send copies of all postings to all moderators, any of whom may approve the message. An example of this would be
is not valid. "All" must appear at the beginning of the list of moderators.
Assuming "Send= Editor, Hold", once a message is approved by one of the moderators, any other moderator attempting to approve the same message will be told that the message cannot be found and has probably expired (since the cookie for that message will be gone).
If the message body is edited in any way before it is approved (i.e., by forwarding an edited copy back to the list), and more than one moderator is involved, duplicates are possible. Thus it is important that the moderators of any list set up this way pay close attention to whether or not the posting has already been approved by another moderator. Note carefully that this means if the "All" parameter is used in "
Moderator=" with "
Send= Editor" (that is, without the "
Hold" parameter), again a separate synchronization method will have to be used to prevent duplicates, as two moderators are unlikely to make exactly the same edits to the message. Even if LISTSERV were able to identify the two submissions as being the same message, it would not know which to choose over the other.
The "Hold" and "
Confirm" options for "
Send=" can also be used with these examples, if desired. L-Soft recommends that "
Confirm" be used by default.
Note: The NOPOST subscriber option will take precedence over both Editor= and Moderator=, if set for someone so defined. This means that if you have "Default-Options= NOPOST" for your list and you add an editor or a moderator as a subscriber, you will have to manually reset the editor to POST (with "SET listname POST FOR userid@host") before things will work properly. You will know that this is necessary if your editor or moderator can successfully approve postings but is then told that he or she cannot post to the list.
Note for moderation "OK" requests and MIME attachment display: In versions previous up to LISTSERV 1.8e, an OK confirmation request for a message coming to a moderated list displayed the message to be approved in its "raw" format; that is, there was no attempt made to display/decode MIME attachments that might be present in the message to be approved. LISTSERV now addresses the problem by including a copy of the first text/plain part (if one exists in the message) for the purpose of quick screening. The following restrictions apply:
1.) This is only done for MIME messages (even simple single-part ones, but they must have MIME headers).
2.) The text part in question is sent pretty much 'as is', that is, as an extra text/plain part in the message, with all the options and encoding and what not supplied in the original message. The reason is quite simply that it would be a lot of work and, in some extreme cases (incompatible code page, etc.), completely impossible, to embed it into the first text/plain part with the LISTSERV message. The drawback is that some mail agents might conceivably only show the first part until you take some kind of clicking action.
It is important to understand that only the first text/plain part is extracted in this fashion. The goal was to make it easier to approve or reject simple text messages, not to build a factory around a simple problem. The ENTIRE message is available at an extra click.
Where security is a concern, it is important to review the ENTIRE original message and not just the plain text part. There could be an obscene GIF or another text part or a text/html part not matching the contents of the text/plain part or whatever. This is why, again, you are given the ENTIRE original message.
List owners using certain email clients (specifically Pine, which handles attachments in a secondary viewing area) may find the new format difficult to use. If preferred, the pre-1.8e behavior may be reverted to by specifying "
NOMIME" in the Send= list header keyword; for instance,
* Send= Editor,Hold,NoMIME
"Semi-moderation" was developed some years ago after a great debate on whether or not an "urgent" message should be allowed to be posted to an edited list without having to go through the approval process. Although this option is still available, it can be misused by anyone who knows about it, and is therefore not generally recommended for use. However, should this feature be deemed necessary, it is activated by setting
Then, any subscriber needing to send an "urgent" message to the list simply types "Urgent:" in the subject line of their mail, followed by the subject of the message. Messages that do not have the "Urgent:" subject are forwarded to the list editor for approval as usual.
In order to minimize the chance of spam slipping through without editorial approval, messages with an "Urgent:" subject originating from non-subscribers will be rejected.
So-called "self-moderated" lists were invented in 1993 or 1994 when the current epidemic of spamming was beginning to get cranked up and before the "spam filter" was developed by L-Soft. With the spam filter in operation, self-moderation is not as much of an issue anymore, but some lists still run this way.
(The "Hold" and "
Confirm" parameters for "
Send=" may naturally be used if required. L-Soft recommends that "
Confirm" be used by default.)
Usually, one of the list owners is the primary editor (here "someone@someplace.com") and the specification of (
listname) makes all of the subscribers of the
listname list editors, and thus eligible to send messages directly to the list without editor intervention. Postings from non-subscribers (e.g., spammers) are deflected to the primary owner for his or her disposition.
There is one caveat to this kind of list. If a user subscribes to the list, and later his mail address changes (for instance, the hostname changes slightly but mail sent to the old address is automatically forwarded to the new address), any postings from him to the list from the new address will be forwarded to the editor because the new address is not subscribed to the list. Thus there is a certain amount of list-owner overhead on this kind of list in keeping track of users whose addresses have changed and modifying the subscriber list to reflect those changes. The "
CHANGE" command can be of help in this regard.
This type of edited or moderated list allows subscribed users to post with editor or moderator intervention, but rejects postings received from non-subscribers with a note to the poster stating that they are not allowed to post.
You should also add Editor= and (optionally)
Moderator= keyword settings to the list. At least one editor must be defined to handle the message approval chores, otherwise the first listed list owner will receive the messages for approval.
An "auto-responder" is a type of list that simply responds with a set message whenever it receives mail from someone. This kind of list can be useful for things like service messages or upgrade availability, or even to simply send back a standardized message to a user who has sent mail to a "support" address.
In other words, it can be very simple, since you probably don't want notebook archives for this kind of auto-responder, you don't want people to subscribe to the list as it isn't really a mailing list, and so forth. To make the auto-response message for this list, you'd then create a
listname.MAILTPL file that includes a
POSTACK1 template, like the following:
This particular template would inform the user that LISTSERV would be down (
&MYNAMES translates to
LISTSERV@NODE where
NODE is the value of
NODE= in the system configuration file) and to send questions to
LSTMAINT@ the local host. In order to change the service message, it would be necessary only to change the
POSTACK1 template.
An "announce-only" list would be used to distribute a newsletter or other timely information where responses to the list are neither expected nor desired. A typical announce-only list header might look like this:
* The FOO Product Announcment List* Owner= foo@myhost.com
* Owner= Quiet:
* Owner= anotheruser@myhost.com
* Owner= yetanotheruser@myhost.com
* Editor= foo@myhost.com
* Editor= anotheruser@myhost.com
* Editor= yetanotheruser@myhost.com
* Notebook= No
* Errors-To= Owner
* Subscription= Open,Confirm
* Validate= No
* Review= Owners
* Send= Editor,Confirm
* Reply-To= foo@myhost.com,Ignore
* Sender= None
This list is set up so that generally any response to postings will go back to foo@myhost.com, which might be a special account set up specifically to handle such things, or a mail alias pointing to another account. The newsletter can be posted by
foo, or
anotheruser, or
yetanotheruser, all of whom are editors, but the likelihood is that it would be posted from the
foo userid so that the From: line would read "From: foo@myhost.com".
L-Soft strongly recommends that all announce-only lists use the "Send= Editor,Confirm" or "
Send=Editor,Hold,Confirm" setting. The "
,Confirm" parameter tells LISTSERV to require a confirmation for any posting sent by a user defined as an
Editor=. This is important for two reasons:
•
Security – This setting tells LISTSERV to request confirmation from the Editor for all postings it receives that purport to be from that Editor. This prevents hackers from forging mail under an Editor's address, because any forgeries will require that the Editor in question approve them before they go to the list.
•
Loop Protection – Certain broken mailers can and will bounce mail back to your list in a "reflected" manner, that is, the bounce will appear to be a legitimate posting from the Editor to the list instead of looking like an error. This is different from a forgery attempt because (it is assumed) the mailer on the other end is not doing this with malicious intent. Requiring the editor confirmation will stop these potential loop-generating messages from getting through to the list.
Sometimes it is desired to send out a little questionnaire before approving a subscription to a list with a very narrowly-defined topic or to lists created for members of specific organizations. By setting "
Subscription= By_Owner", you can of course force all potential subscriptions to require list owner approval. In the "old days", if you wanted more information before you approved the subscription request, you had to manually send a questionnaire out to the user and wait for him or her to return it to you.
By setting "Subscription= By_Owner" and adding two simple template forms to your listname.MAILTPL (as explained in Section 9
Creating and Editing Mail and Web Templates), you can now have LISTSERV send your questionnaire out automatically, as soon as the subscription request is received.
The first template form you need to add to listname.MAILTPL is called
SUB_OWNER, and in this case it would typically look like this:
The .TO &WHOM directive is required so that the message is sent to the subscriber rather than to the list owner. If you want the non-quiet list owners to receive a copy of this message (which is admittedly unlikely), you can simply add
CC: &OWNERS to the end of the
.TO line, for example,
Note: You cannot format the
SUB_OWNER template; it all comes out as one long paragraph without formatting no matter what you do, because it is a "linear" template. But you should modify it from the default to let people know that they will receive a questionnaire to be filled out and returned.
The second template form you need to add to listname.MAILTPL is called
ADDREQ1 and it can be as simple or as detailed as you want. All of the available template formatting commands can be used in
ADDREQ1. For instance:
>>> ADDREQ1 &LISTNAME Membership Survey.RE OWNERS
.TO &WHOM
.CE &LISTNAME Membership Survey
NOTE: Please make sure when you send this back that it goes to the address &LISTNAME-Request@&MYHOST. Thanks.
In this case, you want the message to go to the subscriber, with a Reply-To: header pointing back to the (non-quiet) list owners. The first line indicating the return address is added for those users with mail clients that don't recognize Reply-To: headers.
You can also put a pre-formatted ADD job into the questionnaire to simplify your job when the questionnaire comes back. For instance,
.fo off
----------------------------------------------------------------
-----------------------------------------------------------
// JOB
ADD &LISTNAME &WHOM &USERNAME
// EOJ
-----------------------------------------------------------
.fo on
Occasionally the need to split a very large list may arise. This was more common when LISTSERV ran only on BITNET, whereas the TCP/IP version of LISTSERV is not limited by BITNET constraints. However, because of the fact that subscribers may be scattered all over the world, in rare cases it can make sense to split (or "peer") a list and share the mail load among two or more LISTSERV servers. Peering also makes it possible to have list archives located in more than one place; for example, a list might be peered between a European host and a North American host, making it possible for subscribers on each continent to retrieve archives from the nearer host.
Although there is no problem about peering to another L-Soft LISTSERV list, linking to a non-L-Soft mailing list manager is not supported and can and will cause serious problems (including mailing loops) for which L-Soft international, Inc. could not be held responsible.
The approval request code received together with your posting for the MYLIST-L list is incorrect. For a peered list, this may be a normal condition. The approval protocol is not guaranteed to work among peer chains with pre-1.8b servers, and will also fail if the peers have a different password. For a non-peered list, the only likely explanation is a failure in the mail system or a recent change in mail system version or configuration. At any rate, please resubmit your message and go through the approval procedure a second time, and contact the LISTSERV administrator if the problem persists.
You should be aware of the fact that a MOVE operation is not just an ADD to the new server and a
DELete to the current one. This would effectively transfer the person from the old server to the new one but his distribution options would be lost in the process. Besides, you should make sure that the user does not lose any mail in the process. The proper course of action to be taken when people are moved from one list to the other is the following:
•
If the prerequisites for using the MOVE command are met, you should use either individual
MOVE commands (in the case that there are very few users to move) or a batch-
MOVE command with associated
DDname (see the LISTJOB MEMO guide for more information on commands-jobs) to move the users. You may want to use the
QUIET option to suppress notification if there are a lot of users to move.
Warning: The
MOVE command should not be used to move peer list servers. See the
MOVE command description for more details.
•
Query listname FOR userid@host (old server), write down the options.
•
GET listname (old server)
•
GET listname (new server)
•
If you are using another text editor, then make sure that the editor you are using does not "imbed" control codes such as line breaks, tabs or word-wrapping characters into the text when you edit it. Use the cut and paste controls to copy lines in their entirety. You must preserve the contents of columns 81-100 across the move. Imbedded control codes and/or word wrap will generate errors when the list is stored back on the server.
ADDHere listname userid@host <full_name> <PW=list_password>
The ADDHERE command is strictly identical to ADD, with the exception that the placement of the user is not checked against the list of peer servers; in other words, the specified user is added to the local list without any further verification. (By comparison, the ADD command causes LISTSERV to check automatically to see if there is no better-suited peer list for the specified user.)
EXPLODE listname <F=fformat> [VM only]
The EXPLODE command provides a means whereby a list can be automatically analyzed by LISTSERV to optimize the placement of its recipients over the various peer servers hosting the list. It requires a "Peers=" keyword to be defined in the list header (see the
List Keyword Reference document). Non-BITNET userids will be exploded according to the network address of the corresponding gateway (as per the SERVICE NAMES file), or ignored if the gateway could not be identified. LISTSERV will create a commands-job file containing the necessary
MOVE command to transfer all the users which were found to be (possibly) mis-allocated to the peer server which is nearest to them. This file will then be sent to you so that you can review it before sending it back to the server for execution.
The MOVE command allows list owners to easily move users from one peer server to another. It will move the complete user entry from the source server to the destination one, including full name as it appears in the specified list and all list distribution options. The
MOVE operation will be done in such a way that no mail can possibly be lost by the target while the
MOVE operation is in progress (duplicate mail might be received for a short duration, however). Notification will be sent to the target user unless the QUIET option was used.
If the source and destination list names are identical, only the destination node ('newhost') needs be specified. Otherwise, the full network address ('listid@newhost') must be specified.
The MOVE command requires both source and destination lists to have the same password. Since each server will have to send a password to the other to validate the (special)
ADD/DELETE commands it is sending to the other, it has potentially a way to trap the password specified by the server, thus thwarting any attempt at inventing a protocol to allow use of this command on lists which have a different password. Besides, no
MOVE operation will be accepted on lists which do not have a password at all, because for technical reasons it would allow unauthorized users to easily add someone to a list (since there would be no password validation).
The MOVE command is the proper way to effect a move operation. You should not use any other command/set of commands unless you cannot use
MOVE. THE MOVE COMMAND SHOULD NOT BE USED TO MOVE DISTRIBUTION LISTS!!! Since a
MOVE is basically an
ADD + DELETE, with the latter being done only AFTER the
ADD is completed, moving a distribution list address with the MOVE command can cause a duplicate link to be defined for a short period of time. This could result in a transient mailing loop, which could become permanent if the size of the looping mailfiles is less than the size of the inter-servers "DELETE" command jobfile, and the RSCS priority of the latter has been altered.
It is possible to define a "super-list" (as in opposite of sub-list), that is a "container" list that includes all the subscribers in a predefined set of sub-lists. This can be done recursively to any depth. Site maintainers can create super-lists consisting of any of the lists on the server, regardless of who owns them. A non-maintainer list owner may convert a standard list that they own into a super-list, but they may only add other lists that they own to the Sub-Lists= setting. Attempts by non-maintainer list owners to add non-owned lists to their super-list will result in an error when the list configuration is stored, and the configuration will be left unchanged.
The only difference between a normal list and a super-list is what happens when you post to it. With the super-list, the membership of all the sub-lists is added (recursively) and duplicates are suppressed. Other than that, the super-list is a normal list with its own archives, access control, etc. You can even subscribe to it, and this is actually an important aspect of the operation of super-lists. If you are subscribed to the super-list itself, the subscription options used to deliver super-messages to you are taken from your subscription to the super-list, just like with any other list. All combinations are allowed, and in particular NOMAIL is allowed, meaning you don't want to get messages posted to the super-list. When you are subscribed to multiple sub-lists, on the other hand, things work differently:
•
NOMAIL subscriptions are ignored. You will get the super-message if you have an active (not NOMAIL) subscription to at least one sub-list. The idea is that the super-message must be equivalent to posting to all the sub-lists, without the duplicates. Since all it takes to get a message posted to all the sub-lists is a single non-NOMAIL subscription, this is how the super-list works. The only way not to get the super-messages is to subscribe to the super-list directly and set yourself to NOMAIL.
•
The DIGEST and INDEX options are ignored and internally converted to MAIL. The first reason is that, since in most cases the user will be on multiple sub-lists (otherwise you don't need a super-list in the first place), the only safe method to set subscription options for super-messages is by subscribing to the super-list so that there is no ambiguity. The second reason is that, in most cases, super-lists will be used for out of band administrative messages rather than for large volume discussions, so it is actually preferable to have the message sent directly. The third reason is that the super-list and sub-lists may not necessarily offer the same options (DIGEST and INDEX). In particular it is expected that many super-lists will not have archives. If you want a DIGEST or INDEX for the super-messages, you must subscribe to the super-list directly.
Topics, if defined, are evaluated on a per-list basis. That is, for every sub-list (and for the super-list), LISTSERV determines whether the topic of the message is one that you want to see. If not, it acts as if you were not subscribed to this particular list. Roughly speaking, this works very well if all the sub-lists have the same set of topics (or a well-defined set of common topics), and doesn't work well at all if every list has its own set of topics.
Postings to a super-list are always archived in the super-list's notebooks (if enabled), and never in the notebooks of the sub-lists. This is because by its nature a posting to the super-list is not equivalent to cross-posting a message to all of the sub-lists. Rather, LISTSERV recourses into the sub-lists and generates an "on the fly" listing of all of the users on the super-list and the sub-lists (this is how it avoids duplicates, among other things) and then treats this "on the fly" listing as if it were the subscriber list of the super-list itself. You will note that a super-list posting is always identified as coming from the super-list, regardless of whether a given user is subscribed to the super-list or to one or more of the sub-lists.
Note: A
REVIEW command sent for the super-list will not recourse into the sub-lists pointed to by the super-list. If you have a super-list called SUPER and you send a
REVIEW SUPER command, LISTSERV will respond with only the people who are subscribed directly to
SUPER. The only way to find out what users are covered by the super-list is to send
REVIEW commands for the super-list and all of its sub-lists.
Access to the super-list's notebook archives is not automatically recursive. If you want sub-list subscribers to be able to access the archives of the super-list (but don't want the sub-list subscribers to have to subscribe to the super-list), then you must configure the Notebook= keyword for the super-list so that it contains references to each of the sublists. For example, say we have a super-list called SUPER and two sub-lists called SUB-A and SUB-B. We want the subscribers of both SUB-A and SUB-B to be able to read the archives of SUPER (since postings to SUPER won't be archived in SUB-A or SUB-B), but we don't want people who aren't subscribed to any of the three lists to be able to access the archives. So we set
Some sites may have a need for many lists that are essentially identical. For instance, a series of class section lists for a university department may have the same owner, allow the same class of users to subscribe, and so forth. LISTSERV makes it possible to maintain large collections of lists by "including" keywords from an external file.
For instance, consider a mathematics course with ten sections. Each section should have its own list (for instance, called
M101-001,
M101-002, and so forth), but the lists will otherwise be identical. The LISTSERV maintainer simply creates a text file (in this case called
M101 KEYWORDS) containing the keyword definitions that will be shared by the lists, as follows:
Next, the LISTSERV maintainer stores this file in the usual way, by first making a filelist or catalog entry for it (as outlined in Section 8
File and Notebook Archives) and then storing it with a
PUT operation. Generally the
GET and
PUT FACs for this file should specify that the list owner(s) should be able to retrieve and store it. The file must be stored in LISTSERV’s A directory (the same directory that contains the
*.LIST files).
Note: It is also possible to create this file directly in LISTSERV’s A directory with a text editor; if you do so, make sure that you do not include the
PUT command shown above. You should still make the filelist or catalog entry for the file so that the list owners can retrieve and store it.
The .IK command tells LISTSERV that whenever it uses this list, it should read the keyword definitions from the file
M101 KEYWORDS (note carefully that the syntax is "
.IK M101", not "
.IK M101 KEYWORDS"). Now, whenever the professor in charge of the class wants to make a change to all of the M101 lists (for instance, he has a new graduate assistant), he simply
GETs the file
M101 KEYWORDS, makes the changes, and
PUTs the file back, instead of having to
GET separate headers for each list and make the changes to all of them individually.
Notes: On some servers it may be necessary to stop and restart LISTSERV (or do a
GET+PUT of all of the list headers involved) to make changes to the
KEYWORDS file appear. This is because LISTSERV may have the
KEYWORDS file and/or the list headers that use it cached at the time you modify it.
In order to see the complete list header, send a REVIEW listname command. The response to a
GET will be only the skeleton header with the
.IK command. If
GET did not work this way, you would not be able to change or remove the .IK command line once you set it.
The sample KEYWORDS file above includes a
Notebook= keyword. This will cause the notelogs for all of the lists that use this
KEYWORDS file to be written in the same directory, per the example,
/home/listserv/archives/m101. This means that in that directory you would have notelogs for the
M101-001 list, the
M101-002 list, and so forth (depending of course on what lists use the example
M101 KEYWORDS file). If this behavior is not desired, simply don't put a
Notebook= keyword in the KEYWORDS file, and define it in the list header for the cloned list instead, either before or after the
.IK directive.
For the web archive interface, note carefully that if you do use the same directory for all of the cloned lists' notelogs, you will still have to make separate web archive directories for each list under your
WWW_ARCHIVE_DIR directory if you intend to serve the archives via the web interface. In other words, the web interface doesn't care where you keep a list's notelogs as long as it has a directory specified under
WWW_ARCHIVE_DIR for it to write the list's web archive indexes into. So while all of your notelogs may go into
/home/listserv/archives/m101, regardless of the name of the cloned list, you still need to make (for example)
/usr/local/etc/httpd/htfiles/archives/m101-001 and so forth in order to serve the notelogs on the web.
When creating the list, a random password is assigned for security if the LISTSERV maintainer does not define one explicitly. List passwords are no longer necessary in all but one special situation; they are simply another line of defense, and it is much more secure to allow LISTSERV to randomly assign the list password and for you to use a personal password to validate your LISTSERV commands. See Section 2.9
Defining List Owners to learn how to create a personal password.
The only situation in which a list password MUST be defined explicitly in a list header is in the case of peered lists, where the PW= list header keyword must be set to the same value on all peers.
LISTSERV includes a MIME attachment-filtering feature which is configured at the list level by setting the Attachments= list header keyword. The new keyword allows three distinct modes:
In addition, you can configure specific MIME types to reject or filter while allowing other types through (for instance, you can block executable files but allow images or word processing files based on their MIME type).
This feature is intended primarily to filter out-of-office messages and the like. It is not intended as a profanity filter. Attempts to configure it to filter profanity will most likely prove to be futile in the long run and are not recommended by L-Soft.
The CONTENT_FILTER mail template form, if present, contains filtering rules, one rule per line, empty lines ignored. Each rule has the following format:
The prefix, if present, can be a mail header tag (e.g. "Subject:"); "Header:" to check the whole header; or "Text:" to search the message text. The latter is the default if no prefix is supplied, it is provided in case the pattern contains a colon in the first word. If there are multiple mail header tags with the specified name (e.g. "Received:"), each such tag is searched and it is enough for one of them to match the pattern. If the requested tag is not present in the header, there is (surprise!) no match. A text search will search every line of the first text/plain part in the message. If there is no text/plain part, there is no match. Again, this is designed to filter read receipts, loops, chain letters, spam, you name it. There was no attempt on the developers' part to make this a profanity filter, and future versions will not be "enhanced" to make futile attempts at (for instance) decoding Word documents to look for obscene words.
Regular comparisons such as those described above are not case sensitive. Patterns are standard LISTSERV patterns, that is, the asterisk is the wildcard character. If there is no asterisk in the pattern, it is replaced with "*pattern*" much like the SCAN command.
Documented Restriction: You cannot match literal asterisk characters in a string as there is no way to escape them. Any asterisk in a pattern will always be evaluated as a wildcard.
•
You can make an exact match for the empty string. Empty regular matches are ignored since they map to a wildcard comparison for **, which would be always true. This also makes it possible to apply an exact match to a message that does not contain a specified header. For instance, if you want all messages to contain a (mythical) KABOOM: RFC822 header, with an exact match you can tell LISTSERV to perform one of the content-filtering actions if the the header is not present. This is not possible with a regular match.
Note: You cannot differentiate a header with an empty KABOOM field from a header with no KABOOM field.
Subject::Action: REJECT Please resubmit your message with a non-blank subject.
Action: ALLOWAction: REJECT reason
Action: DISCARD comment
Action: MODERATE
>>> CONTENT_FILTER Subject: Out of office
Action: REJECT OOO messages are not allowed on this list.
Subject: Auto-Generated:
Action: REJECT
Text: Click here to be removed
Action: REJECT Buzz off, spammer.
Subject::
Action: REJECT Please resubmit with a non-blank subject.
Subject: copyright
Action: MODERATE
To: friend@public.com
Action: DISCARD This guy is a spammer
The default is "Action: REJECT" with no specified reason. REJECT means that the message is rejected. MODERATE means that the message is to be forwarded to the list editor to be manually approved or rejected. DISCARD means that the message is to be dropped on the floor without further processing; any text following DISCARD is echoed to the LISTSERV console (and is thus logged).
ALLOW means that the message is allowed and all remaining rules are ignored. This could be used in moderated lists to allow the list moderator to bypass certain filters, for instance:
>>> CONTENT_FILTER Subject: Out of office
Action: REJECT OOO messages are not allowed on this list.
From: JOE@EXAMPLE.COM
Action: ALLOW
Text: Click here to be removed
Action: REJECT Buzz off, spammer.
In the example above, messages with Subject: lines containing "Out of office" are rejected. Messages containing the text "Click here to be removed" are also rejected UNLESS they come from joe@example.com.
The text of the rejection is fetched from the BAD_CONTENT mail template form, with the reason supplied as a variable called &COMMENT. The rejection message looks like this:
Date: Tue, 4 Dec 2001 22:03:42 -0500From: "L-Soft list server at LISTSERV.EXAMPLE.COM (1.8e)"
<LISTSERV@LISTSERV.EXAMPLE.COM>
Subject: Rejected posting to TEST@LISTSERV.EXAMPLE.COM
To: Joe User <joe@EXAMPLE.COM>
A default site-wide CONTENT_FILTER template form may be defined in
$SITE$.MAILTPL for use by lists whose owners do not prefer to provide their own custom versions in their
listname.MAILTPL files.
DomainKeys message signing is available to sites running LISTSERV Classic or LISTSERV Classic HPO. Current LISTSERV maintenance is also required. For more information on how to configure LISTSERV for DomainKeys support, please contact your site administrator.
Assuming that it is available for your use, DomainKeys support for lists is enabled by default. This means that all list postings and administrative messages related to a list will be signed to assert that they actually originated from your LISTSERV server.
Incoming DomainKeys or DKIM signatures submitted to a mailing list will be removed unless "
Misc-Options= KEEP_DKIM_SIGNATURE" is set in the list configuration. This is necessary because these signatures almost never match after the message has been processed. The worst thing that could possibly happen to your deliverability is a DomainKeys signature that does not match and causes the message to be flagged as suspicious.
The KEEP_DKIM_SIGNATURE option is experimental and not meant for general use. As DomainKeys is specified today, signatures DO NOT survive posting to mailing lists (LISTSERV or otherwise), so LISTSERV removes them by default to avoid triggering alerts for subscribers on systems that have implemented the client side of DomainKeys. The DKIM specification may be more robust in this respect, but even DKIM signatures will probably not survive when posted through a mailing list. Use the KEEP_DKIM_SIGNATURE option at your own risk.
